High-capacity transport networks such as optical transport networks (OTNs) have heretofore been successfully used for providing end-to-end connectivity between customer sites adapted to transmit and receive certain types of client signals. In a typical scenario, shown in FIG. 1, a customer site 105 transmits a client signal having a certain client signal format to an ingress interface 100 such as a hub or central office (CO). The ingress interface 100 is connected to the OTN 110 by a high-capacity link 120 such as an optical fiber. The client signal received by the ingress interface 100 is intended to be transmitted to another customer site 125 connected to the OTN 110 via an egress interface 130 (such as another hub or central office) and a corresponding high-capacity link 140.
The ingress interface 100 typically encapsulates the client signal within a transport signal that adheres to a format known as a transport signal format. In most existing OTNs, the transport signal format and the client signal format are not independent. Rather, when setting up the OTN to service a group of large or medium-sized customers, the transport signal format is carefully chosen to simplify encapsulation of client signals having a client signal format commonly used by those customers. An example of a popular client signal format is the SONET OC-48 client signal format which refers to a frame-based Synchronous Optical NETwork Optical Carrier signal having a bit rate of 48 times the basic OC-1 rate of 51.84 Mbps.
By way of example, a transport signal format which was specifically designed to simplify the encapsulation of client signals in the OC-48 format is the so-called G.975 format as defined in ITU Recommendation G.975 “Series G: Transmission Systems and Media; Digital System and Networks; Digital Transmission Systems—Digital Sections and Digital Line System—Optical Fibre Submarine Cable Systems; Forward Error Correction for Submarine Systems” and incorporated by reference herein in its entirety.
There exist other transport signal formats which provide simplified encapsulation of client signals having a limited number of other client signal formats used by large and medium-sized “legacy” customers. As a result, most OTNs in use today are able to accommodate transport signals having a transport signal format that facilitates the encapsulation of client signals adhering to one or another of a limited number of client signal formats.
However, as the thirst for seamless end user connectivity grows, so does the diversity of customers desirous of reaping the benefits of a high-capacity OTN. Thus, a new generation of customer has appeared alongside the more traditional large and medium-sized legacy customer. Many of these newer customers utilize equipment which produces client signals in a format which is not easily encapsulated by the transport signal formats currently used in most existing OTNs. As a result of the incompatibility existing between today's OTNs and many of the “nontraditional” client signal formats employed by an emerging customer base, end-to-end connectivity and its myriad potential benefits are seldom realized.
A possible solution would be to change the transport signal format used within an existing OTN in order to accommodate encapsulation of client signals having new, nontraditional formats. However, a large investment in OTN infrastructure depends on the chosen transport signal format and thus any change to the transport signal format would lead to a prohibitively expensive overhaul of many backbone networks in use today. Moreover, the legacy customers around which existing OTNs were built have not disappeared from the scene. This raises a complexity issue since access to existing OTNs must not only be provided to a new breed of customer but such access must continue to be provided to customers who employ the more traditional client signal formats.